計畫會演化、核准會失效——那反過來問：一次有效的核准，到底長什麼樣？今天把本系列真實發生過的那一次攤開來看。核心主張是：核准是可驗證的證據，不是一句好話；它得回答四個問題——誰、什麼時候、對哪一版、為什麼。

證據本體在 series/review/decisions.json，那筆紀錄的欄位如下：decision 是 approve；decision_id 是 dec-fad493250fa5；reviewer 是 bensonwiseiot；reviewed_at 是 2026-08-04T15:41:16Z；plan_sha256 是 8ae53557bcb43543ece5… 開頭的那串 v1 指紋；reason 寫著「作者明確核准目前完整 30 天規劃，並要求撰寫 Day 1」。四個問題，四個欄位，一個都不缺。對照 Day 9 的標準，老闆當時的核准語句明確覆蓋了當前 hash——不是「不錯」，不是「繼續」，是指名道姓的點頭。

系統的反應同樣有據可查：那筆核准落地後，checklist 裡綁著 8ae535… 的 plan-approval 檢查項從 open 轉為 closed——這筆狀態變化至今還留在 series/review/checklist.json 裡，時間戳是 2026-08-04T15:41:16Z，跟決定紀錄同一秒；current_plan_approved 轉為 true，Day 1 的初稿這才有資格出生。從「老闆說可以」到「系統確認可以」，中間沒有任何一步靠默契。

但這裡要補一個此刻的誠實註記，免得本篇讀起來像大結局：核准是對特定 hash 的事實，不是一勞永逸的身分。2026-08-14 我重跑了一次驗證：validate 回 exit 0，validate --formal 回 exit 8，狀態摘要裡的 current_plan_approved 是 false。原因不神祕——經過 Day 20 那兩次需求變更，當前計畫已經是 v3，而 v1 的那筆 approve 仍然真實、仍然在案，只是它效力所及的那一版計畫已經退役。核准紀錄跟工作證一樣：真的，但要看發證日期跟適用範圍。

還有一條界線劃清楚：計畫核准解鎖的是「按這張班表逐篇開工」，不是「這 30 篇寫什麼都算數」。每一篇的正文照樣要過逐篇審稿，發布照樣要另外授權——閘門是一道一道過的，沒有一張票通到底這種好事。

白紙黑字，附指紋，載明理由與時效——這才叫核准。其他的，都只是聊天。